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DESCRIPTION 
DATALOG SUPPORT IN A MODULAR TEST SYSTEM 

CROSS-REFERENCE TO RELATED APPLICATIONS 
[0001] This application claims the benefit of provisional application no. 60/573,577, 
"Software Development in an Open Architecture Test System " filed by Advantest 
Corporation on May 22, 2004, which is incorporated herein in its entirety by reference. 

FIELD OF THE INVENTION 
[0002] The present invention relates to the field of automated test equipment (ATE). 
In particular, the present invention relates to a method and system for supporting datalog in 
an open architecture test system. 

BACKGROUND OF THE INVENTION 
[0003] The increasing complexity of System-on-a-Chip (SOC) devices and the 
simultaneous demand for a reduction in the cost of chip testing has forced both integrated 
circuit (IC) manufacturers and tester vendors to rethink how IC testing should be 
performed. According to industry studies, without re-engineering the projected cost of 
testers will continue to rise dramatically in the near future. 

[0004] A major reason for the high cost of test equipment is the speciaUzed nature of 
conventional tester architecture. Each tester manufacturer has a number of tester platforms 
that are not only incompatible across companies such as Advantest, Teradyne and Agilent, 
but also incompatible across platforms within a company, such as the T3300, T5500 and 
T6600 series testers manufactured by Advantest. Because of these incompatibilities, each 
tester requires its own specialized hardware and software components, and these 
specialized hardware and software components cannot be used on other testers. In addition, 
a significant effort is required to port a test program from one tester to another, and to 
develop third party solutions. Even when a third party solution is developed for a platform, 
it cannot be ported or reused on a different platform. The translation process from one 
platform to another is generally complex and error prone, resulting in additional effort, 
time and increased test cost. 
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[0005] Datalogging is used to provide status information to the user when running a 
test or a series of tests. The information reported in a datalog may include the pass/fail 
status of the device under test (DUT), any relevant measured parameters, and the overall 
run status of the test itself. This information is typically used offline to assess the 
5 completion of a test run and tiie performance of the device being tested. The support of 
datalog capabilities allows users to output their test information jfrom a designated source 
to a designated destination in a desired format. 

[0006] One of the problems of the specialized tester architecture is that all hardware 
and software remain in a fixed configuration for a given tester. To test a hardware device 

10 or an IC, a dedicated test program is developed that uses some or all of the tester 

capabilities to define the test data, signals, waveforms, and current and voltage levels, as 
well as to collect the DUT response and to determine DUT pass/fail. 
[0007] Since a test system needs to exercise a wide range of functionalities and 
operations in order to test a wide variety of test modules and their corresponding DUTs, 

1 5 there is a need for an open architecture test system that can be configured to support the 
wide variety of test modules. Specifically, in order to support the wide variety of test 
modules, there is a need for a datalog framework within the open architecture test system 
that can be configured to work with the different formats of the different sources and 
destinations of the test system. 

20 SUMMARY 

[0008] In one embodiment of the present invention, a metiiod for communicating test 
information firom a source to a destination includes providing a modular test system, where 
the modular test system comprises a system controller for controlling at least one site 
controller, the at least one site controller for controlling at least one test module. The 

25 method fijrther includes providing a datalog framework for supporting extension of user- 
defined datalog formats, providing support classes for supporting user-initiated datalog 
events, receiving a datalog event requesting for communicating input test information from 
the sovirce to the destination, configuring output test information based upon the 
destination, the datalog firamework and the support classes, and transferring the output test 

30 information to the destination. 

[0009] In another embodiment of the present invention, a modular test system includes 
a system controller, at least one site controller coupled to the system controller, at least one 
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test module and its corresponding device under test (DUT), a datalog framework 
configured to support extension of user-defined datalog formats, and one or more support 
classes configured to support user-initiated datalog events. The modular test system 
further includes means for receiving a datalog event requesting for communicating input 
5 test information from the source to the destination, means for configuring output test 

information based upon the destination, the datalog framework and the support classes, and 
means for transferring the output test information to the destination. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0010] The aforementioned features and advantages of the invention as well as 
10 additional features and advantages thereof will be more clearly understood hereinafter as a 
resiilt of a detailed description of embodiments of the invention when taken in conjunction 
with the following drawings. 

[0011] Figure 1 illustrates an open architecture test system according to an 
embodiment of the present invention. 
1 5 [0012] Figure 2 illustrates an implementation of a datalog framevvork according to an 
embodiment of the present invention. 

[0013] Figure 3 illustrates an implementation of datalog sources according to an 

embodiment of the present invention. 

[0014] Figure 4 illustrates a method for registering source types according to an 
20 embodiment of the present invention. 

[0015] Figure 5 illustrates a method for formatting and streaming data according to an 
embodiment of the present invention. 

[0016] Figure 6 illustrates an implementation of enabling datalogging dynamically 
according to an embodiment of the present invention. 
25 [0017] Figure 7 illustrates an implementation of disabling datalogging dynamically 
according to an embodiment of the present invention. 

[0018] Figure 8 illustrates an implementation of modifying datalog format dynamically 
according to an embodiment of the present invention. 

[0019] Figure 9 illustrates an implementation of assigning datalog output streams 
30 dynamically according to an embodiment of the present invention. 

[0020] Figure 1 0 illustrates an implementation of disabling datalog output stream 
dynamically according to an embodiment of the present invention. 
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[0021] Figure 1 1 illustrates an implementation of adapting new source dynamically 
according to an embodiment of the present invention. 

DESCRIPTION OF EMBODIMENTS 
[0022] Methods and systems are provided for datalog support in a modular test system. 
5 The following description is presented to enable any person skilled in the art to make and 
use the invention. Descriptions of specific techniques and applications are provided only 
as examples. Various modifications to the examples described herein will be readily 
apparent to those skilled in the art, and the general principles defined herein may be 
applied to other examples and applications without departing from the spirit and scope of 
1 0 the invention. Thus, the present invention is not intended to be limited to the examples 
described and shown, but is to be accorded the widest scope consistent with the principles 
and features disclosed herein. 

[0023] Figure 1 illustrates an open architecture test system according to an 
embodiment of the present invention. A system controller (SysC) 102 is coupled to 

15 multiple site controllers (SiteCs) 104. The system controller may also be coupled to a 
network to access associated files. Through a module connection enabler 106, each site 
controller is coupled to control one or more test modules 108 located at a test site 110. The 
module connection enabler 106 allows reconfiguration of connected hardware modules 108 
and also serves as a bus for data transfer (for loading pattern data, gathering response data, 

20 providing control etc.). In addition, through the module connection enabler, a module at 
one site can access a module at another site. The module connection enabler 106 allows 
different test sites to have the same or different module configurations. In other words, 
each test site may employ different numbers and types of modules. Possible hardware 
implementations include dedicated coimections, switch connections, bus coimections, ring 

25 connections, and star connections. The module connection enabler 106 may be 

implemented by a switch matrix, for example. Each test site 1 10 is associated with a DUT 
112, which is connected to-the modules of the corresponding site through a loadboard 1 14. 
In another embodiment, a single site controller may be connected to multiple DUT sites. 
[0024] The system controller 102 serves as the overall system manager. It coordinates 

30 the site controller activities, manages system-level parallel test strategies, and additionally 
provides for handler/probe controls as well as system-level data-logging and error handling 
support. The system controller 102 is the primary point of interaction for a test engineer in 
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verifying and debugging the test environment. It provides a gateway to the site controllers 
104, and manages the synchronization of the site controller activities in a multi-DUT 
environment. It further runs user applications and tools, such as the Datalog graphical user 
interface (Data'logGUI). Depending on the operational setting, the system controller 102 
can be deployed on a CPU that is separate from the operation of site controllers 104. 
Alternatively a conunon CPU may be shared by the system controller 102 and the site 
controllers 104. Similarly, each site controller 104 can be deployed on its own dedicated 
CPU (central processing unit), or as a separate process or thread within the same CPU. 
[0025] The site controllers 1 04 are responsible for rurming a test plan to test the DUTs. 
The test plan creates specific tests by using the Framework Classes as well as standard or 
user supplied Test Classes that encapsulate the test methodology. In addition, the test plan 
configures the hardware using the Standard Interfaces, and defines the test flow. 
[0026] The system architecture of the present invention may be conceptually 
envisioned as the distributed system shown in Figure 1 with the understanding that the 
individual system components may also be regarded as logical components of an integrated, 
monolithic system, and not necessarily as physical components of a distributed system. 
The plug-and-play or replaceable modules are facilitated by use of standard interfaces at 
both hardware and software levels. A tester operating system (TOS) allows a user to write 
test plan programs using a test plan programming language, and to operate the test system 
in a way specific to a particular device under test (DUT). It also allows the user to package 
sequences of the test system operations commonly used in test plan programs as libraries. 
These libraries are sometimes referred to as test classes and test templates. 

Datalog Framework 

[0027] The datalog firamework runs on individual Site Controllers, along with the test 
plan and the system fi:amework classes. It provides a set of interfaces, classes and methods 
to support the development, deployment and management of the datalog system. The 
datalog firamework 

• manages datalog elements, such as sources, streams and formatters; 

• dispatches datalog events; 

• provides an application programming interface (API) that allows the 
creation of new datalog events; 

• provides APIs to set up and control datalogging; 
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• provides a general purpose formatter to handle common formatting needs; 
and 

• provides support for the integration of modular third party and/or 
customer datalog services, which makes the datalog frameworlc open. 

5 Standard Datalog Interfaces 

[0028] Figure 2 illustrates an implementation of a datalog framework according to an 
embodiaient of the present invention. The set of relationships among the datalog 
framework interfaces and support classes are illustrated through the unified modeling 
language (UML) class diagrams of Figure 2. The datalog framework 200 includes a 

1 0 datalog stream interface 202, a datalog format interfece 204, a datalog type interface 206, 
and a datalog source interface 208. The datalog framework 200 further includes a datalog 
manager class 210, a datalog format map class 212, a datalog format group class 214, a 
datalog values class 216, a general format class 218, and a user format class 220. 
[0029] The standard datalog interfaces to the tester operating system (TOS) are defined 

1 5 as pure abstract C++ classes. The datalog stream interface (IDatalogStream) 202 represents 
an output file or device. The datalog system sends formatted output to streams. The 
system provides two built-in streams, a FileStream for sending output to a local disk file, 
and a ConsoleStream for sending output to the System's Console application. 
[0030] The datalog format interface (IDatalogFormat) 204 represents the necessary 

20 instructions required to format data associated with datalog events to an output. The 
specific nature of the formatting capability is hidden inside each implementation of the 
IDatalogFormat. For example, the built-in GeneralFormat allows a general format string to 
be used vwth a macro-like capability for extracting named values from the DatalogValues 
objects, and inserting them into a formatted string. 

25 [0031] The datalog type interface (IDatalogType) 206 represents a class or a "type" of 
datalog source, such as a particular type of a Test. The DatalogManager 210 maps events 
to formats and streams based in part on the type of the source of the event. As new types 
of sources are created, they register themselves with the DatalogManager 210 and receive 
an identifier (ID) value. Managing these types allows the DatalogManager 210 to 

30 enable/disable whole classes of datalog sources as well as specific instances of datalog 
sources. The IDatalogType objects 206 may generate multiple classes of datalog events. 
For example, a user test that loops over a set of patterns until some condition occurs may 
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generate TestStart, TestEnd, IterationStart, IterationEnd, and ConditionTest datalog events. 
Each of these classes of events may have different data fields associated with it (see 
DatalogValues class below). 

[0032] The datalog source interface (IDatalogSource) 208 represents a source of 
5 datalog events. While the IDatalogType 206 characterizes an entire class of datalog source 
objects, the IDatalogSouxce 208 represents an individual source instance. Tliis interface 
allows enabling/disabling datalogging of individual sources. 

Datalog Support Classes 

[0033] A central object of the datalog framework 200 is the DatalogManager object 
10 210. This object is responsible for maintaining all datalog output streams as well as 
formatting and forwarding datalog events and their associated data to the appropriate 
stream(s). The DatalogManager 210 resides in the test plan server (TPS) of the Site 
Controller. It is the datalog execution engine. Specifically, the main functions of the 
DatalogManager 210 include: 
1 5 • Managing a set of global datalog streams (i.e., objects implementing the 

IDatalogStream interface). 

• Managing a set of datalog formats (i.e., objects implementing the 
IDatalogFormat interface), each of which generates a formatted string as a 
result of a set of datalog events. 

20 • Distributing the datalog events to all associated datalog streams. All 

destinations for streams can be controlled through the DatalogManager. 

• Maintaining and controlling Datalog Mask conditions, which have the 
effect of filtering datalog output. Note that the application of the mask 
may occur at the source to improve system performance. 

25 • Starting up/cleaning up the datalog system. 

• Enabling/disabling the entire datalog system, as well as individual datalog 
types or sources. 

[0034] The datalog format map class 2 1 2 is a named <EventType, EventName, 
Format> combination. That is, it groups together an EventType (representing a specific 
30 IDatalogType object), an EventName (representing one of the datalog events generated by 
EventType objects) and a Format (representing an IDatalogFormat object). 
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[0035] The datalog format group class 2 1 4 is a collection of DatalogFormalMap 
objects. Users may bundle DatalogFormatMap objects into a single group and assign the 
group to a stream or several streams. This provides the user-level control over the ultimate 
formatting of datalog events and the routing of these formatted strings to the appropriate 
5 streams. 

[0036] The datalog values class 216 contains header information, like datalog type 
identifier and event, and a list of datalog fields that are set by the event sovirce. The 
DatalogValues object acts as a string-to-string map, from name to value, allowing format 
objects to extract the required values by name, and insert them into a formatted stream. 

1 0 [0037] The general format class 2 1 8 is an unplementation of IDatalogFormat. It allows 
a general format string to be used with a macro-like capability for extracting named values 
from the DatalogValues objects, and inserting them into a formatted string. 
[0038] The user format class 220 is a placeholder for a user-defined format class. If 
the supplied GeneralFormat class does not meet a user's specific requirements, one may 

1 5 add a new format class to the system and make use of it. 

Datalog Sources 

[0039] In one embodiment, a Site Controller based object may act as a source of 
datalog events by implementing an IDatalogSource interface 208. For example, the Test 
Plan and Test objects are examples of sources of events. Each instance of such an object 

20 implements the IDatalogSource interface. In addition, each type of such an object, for 
example FunctionalTest, has an implementation of the IDatalogType interface 206 
associated with it. This is accomplished vnth a class-wide static object for each type of 
datalog source. Figure 3 illustrates an implementation of datalog sources according to an 
embodiment of the present invention. The datalog sources include a ftinctional test () class 

25 302, a datalog type implementation () class 304, the datalog type interface 306 and the 
datalog source interface 308. 

[0040] As shown in Figure 3, the FunctionalTest class 302 has a class-wide static 
member of type DatalogTypelmpl 304. An instance of the FunctionalTest checks this 
member variable when it is created. If the variable has not been created and assigned, then 
30 the constnictor creates an instance of DatalogTypelmpl, initializes it, assigns it to the static 
member variable, and registers it with the DatalogManager. A subsequent instance of the 
FunctionalTest class accesses the DatalogTypelmpl data member, and adds itself (i.e., the 
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instance of the FunctionalTest as an IDatalogSource) to DatalogTypelmpl's list of datalog 
source instances that the latter FunctionalTest instance is serving. 
[0041] In another embodiment, a sub-class of the FunctionalTest class, for example 
ADifferentFunctionalTest, may attempt to establish a datalog type different from that of 
5 the FunctionalTest. An implementation of ADifferentFunctionalTest may accomplish this 
by not using the class-wide DatalogTypelmpl associated with the FunctionalTest, but using 
its own class-wide instance of a DatalogTypelmpl. Note that each instance of 
FunctionalTest implements the IDatalogSource interface. DatalogTypelmpl uses this 
interface to enable/disable individual sources. 

1 0 Source Type Registration 

[0042] When a Test Plan is loaded, datalog event sources may register with the 
DatalogManager object. The return value from this registration is an identifier, which is 
then used to generate events. 

[0043] Figure 4 illustrates a method for registering source types according to an 
1 5 embodiment of the present invention. The group of collaborating objects for registering 
source types includes a Test Plan object 402, a FunctionalTestl object 404, a 
FunctionalTest2 object 406, and a DatalogManager object 408. Note that when the Test 
Plan creates two test instances of the same type (FunctionalTestl and FunctionalTest2), the 
first test instance registers a new datalog type with the DatalogManager. 
20 [0044] Users may set datalog formats for different event types. This may be done 
during Test Plan initialization to provide default formats and/or done interactively from 
remote applications. A similar procedure is followed to allow users to set the datalog 
streams. The DatalogManager maintains a mapping from a set of {datalog-type, datalog- 
event} to a corresponding set of {datalog-format, datalog-stream} that specifies the route 
25 an event of a particular type may take through the test system. For file-based streams, a 
Test class on the Site Controller may close the stream allowing the datalog file to be 
transferred to the System Controller. The stream may then be reopened or replaced with 
another stream. 

30 Formatting and Streaming Data 

[0045] During testing, an object may generate a datalog event that is logged to a data 
stream. Figure 5 illustrates a method for formatting and streaming data according to an 
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embodiment of the present invention. The group of collaborating objects and interfaces for 
performing this taslc include a Test Plan object 502, a DatalogValues object 504, a 
DatalogManager object 506, a datalog format interface (IDatalogFormat) 508 and a datalog 
stream interface (IDatalogStream) 510. The Test Plan 502 creates the DatalogValues 
object instance 504, sets the appropriate values by calling the setValueQ method, and 
passes this object to the doDatalogQ method of the DatalogManager 506. The doDatalog() 
method then finds the appropriate datalog format object 508 for the type/event combination, 
and calls the applyO method on this datalog format object 508 to obtain a string object in 
return. This string object is then passed to the associated datalog stream object 510 for 
output using the writeMessageQ method. 

Datalog Initialization 

[0046] In a different embodiment, the datalog system is initialized using the following 
steps: 

• create datalog stream(s) and add them to the DatalogManager. 

• create datalog format(s) and add them to the DatalogManager. 

• create datalog format map(s) and add them to the DatalogManager. 

• create datalog format group(s) and add them to the DatalogManager. 
[0047] The datalog application programming interface (API) provides functions to 
perform the above tasks. In addition, the test system provides a Test class, 
DatalogSetupTest, which reads one or more configuration files and performs the above 
steps. The example below illustrates the use of the DatalogSetupTest configuration file to 
perform the initialization steps. The DLL parameter within the datalog stream, datalog 
format map and datalog format group specifies a library to use for implementing the 
IDatalogStream 202 or IDatalogFormat 204. 

Version 0.1.0; 

# Enable the datalog system 
Enabled; 

# Step 1 : Stream Creation 

# Creates a stream of type FileStream, which logs the message to 

# a file. 

Stream FunctionalTestStream 
{ 

DLL "FileStream"; 

FileName "FuncDatalogDut<DutID>.log"; 
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Overwrite "1"; 

} 

# Step 2: Format Creation 

# Adds a fonnat with a line that looks like: 

# Signallnfo: $SignalInfo 

# where $SignalMo is replaced by the string provided in the datalog 

# source. 

Format SignallnfoFormat 
{ 

DLL "GeneralFormat"; 

Format "Signal Info: $SignalInfo"; 
} # Adds a foraiat with a line that looks like: 

# Test Result: $Result 

# where $Result is replaced by the string provided in the datalog 

# source. 

Format TestResultFormat 
{ 

DLL "GeneralFormat"; 
Format "Test Resuh: $Result"; 

} 

# Step 3: FormatMap Creation 

# Maps format SignallnfoFonnat to event DumpSignal from sources 

# of type com.Advantest.oai.TestClasses.FunctionalTest. 
FormatMap SignalFormatMap 

{ 

Type com.advantest.oai.TestClasses.FunctionalTest; 
Event DumpSignal; 
Format SignallnfoFormat; 

} 

# Maps format TestResultFormat to event TestResult from sources 

# of type com.Advantest.oai.TestClasses.FunctionalTest. 
FormatMap ResviltFormatMap 

{ 

Type com.advantest.oai.TestClasses.FimctionalTest; 
Event TestResult; 
Fonnat TestResultFormat; 

} 

# Step 4: FormatGroup Creation 

# Creates a group which directs messages from format map 

# SignalFormatMap and ResultFormatMap to destination FunctionalTestStream 

# and ConsoleStream. 
FormatGroup FunctionalTestGroup 

{ 
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FormatMap SignalFonnatlVIap; 
FormatMap ResultFormatMap; 

Stream FunctionalTestStream; 
5 Stream ConsoleStream; 

} 

Semantics of Datalog Setup File 

[0048] In yet another embodiment, a datalog setup file includes four different types of 
blocks: datalog format blocks, datalog stream blocks, datalog format map blocks and 

10 datalog format group blocks. These blocks are used to define the datalog formats, datalog 
streams, datalog format maps and datalog format groups respectively. Any of these four 
blocks may be used multiple times in a same setup file, and the datalog system may also be 
set up with multiple separate datalog setup files. Thus, the datalog system setup is modular 
and flexible. For example, there may be a first datalog setup file for setting up Cal/Diags 

1 5 datalogging, a second datalog setup file for setting up datalogging for functional tests, and 
a third datalog setup file for setting up datalogging for parametric tests. 

Datalog Format Block 

[0049] In one embodiment, a datalog format block is used to define a datalog format. 
The definitions of the format may include a format name, a format DLL name, a message 
20 format string and optional user-defined format parameters. If the format DLL name is 
GeneralFormat, the predefined GeneralFormat is used; otherwise, a user-defined datalog 
format is used. In the latter case, the user provides a datalog format DLL in the system test 
directories. The following Datalog API is called to define the datalog format block: 
void DatalogManager;:addFormat(const OFCSfaing &formafName, 
25 const OFC String &typeName, 

const OFCString &format, 
const DatalogProperties_t properties); 

and 

Format SignallnfoFormat 
30 { 

DLL "GeneralFormat"; 
Format "$SignalInfo"; 

} 
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defines a format SignallnfoFormat, which makes use of the predefined GeneralFormat. Its 
fomat string is $SignalInfo, in which SSignallnfo is a token which may be replaced by the 
datalog variable Signallnfo in the passed-in datalog record (Datalog Values) during runtime 
A datalog format block can be used to remove an existing datalog format from the datalog 
5 system. In this scenario, the following datalog API is called. 



removes datalog format AnExistingFormat from the datalog system. 

Datalog Stream Block 

15 [0050] In another embodiment, a datalog stream block is used to define a datalog 

stream. The definition of the datalog stream includes a stream name, a stream DLL name 
and optional user-defined stream parameters. If the stream DLL name is FileStream or 
ConsoleStream, a built-in datalog stream FileStream or ConsoleStream is used; otherwise, 
a user-defined datalog stream is used. In the latter case, the user provides a datalog stream 

20 DLL in the system test directories. The following Datalog API is called to define the 
datalog stream block: 



void DatalogManager::removeFormat(const OFCString &formatName); 



and 



10 



Format AnExistingFormat Disabled; 



25 



void DatalogManager::addStream(const OFCString &streamName, 

const OFCString &typeName, 
const DatalogProperties_t properties); 



and 



Stream FunctionalTestStream 
{ 



30 



DLL "FileStream"; 



FileName "datalog<DutID>.log"; 



Overwrite "0"; 

} 



35 



defines a stream FunctionalTestStream, which makes use of the built-in stream FileStream 
with optional parameter FileName and Overwrite. Note that FileSla-eam supports a file 
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name with automatic variables <DutID> and <TimeStamp>. The <DutID> is replaced by 

the current DUT ID during runtime while the <TimeStamp> is replaced by the current date 
and time with format such as Thu_Nov_13_06_40_28_2003. 

[0051] A datalog stream block can be used to remove an existing datalog stream from 
5 the datalog system. In this case, the foUowuig datalog API is called: 

void DatalogManager::removeStream(const OFCString &streamName); 

and 

10 Stream AnExistingStream Disabled; 

removes datalog stvoom AnExistingStream from the datalog system. 
Datalog Type Block 

[0052] In a different embodiment, a datalog type block is used to define user-specific 
1 5 properties for a datalog type. The following Datalog API is called to define the datalog 
type block: 

IDatalogType *DatalogManager::getType(const OFCString &typeName) 
const; 

20 void IdatalogType::addProperty(const OFCString &propName, 

const OFCString &prop Value); 

and 

Type com.Advantest.oai.TestClasses.FunctionalTest 
25 { 

Mode "Detailed"; 

} 

defines a property Mode with value "Detailed" for datalog type 
30 "com.Advantest.oai.TestClasses. FunctionalTest." 

Datalog Format Map Block 

[0053] In yet another embodiment, a datalog format map block is used to define a 
datalog format map. The definition of the Fomiat Map includes a format map name, a 
datalog type name and its event name to be mapped, and a mapped format name. The 
35 following Datalog API is called to define the datalog format map block: 
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void DatalogManager::createFonnatMap(const OFCString &mapName, 

const OFCString &typeName, 
const OFCString &eventName, 
const OFCString &formatName); 

5 

and 

FormatMap SignalFormatMap 
{ 

Type com.Advantest.oai.TestClasses.FunctionalTest; 
10 Event Dumps ignal; 

Format SignaltafoFormat; 

} 

defines a format map SignalFormatMap, which maps datalog type 
1 5 com.Advantest. oai. TestClasses.FmctiomlTest and its event DumpSignal to format 
SignallnfoFormat. 

[0054] A datalog format map block may be used to remove an existing datalog format 
map from the datalog system. In this case, the following datalog API 

20 void DatalogManager: :removeFormatMap(const OFCString &mapName); 

is called to perform the task. 
Datalog Format Group Block 

[0055] In one embodiment, a datalog format block is used to define a datalog format 

25 group. The definition of the Format Group includes a format group name, a list of names 

of format maps that the format group contains, and a list of names of streams to which 

messages generated from the format group are exported. The following Datalog APIs are 

called to define the datalog format group block: 

void DatalogManager::createFormatGroup(const OFCString &groupName, 
3 0 const OFCStringVecJ; &mapNaraes) ; 

void DatalogManager: :setStream(const OFCString &groupName, 
const OFCString &streamName); 

The first call creates a format group that contains a vector of formats, and the second call 
35 adds a datalog stream into the created format group. For example, 
FormatGroup FunctionalTestGroup 
{ 

FormatMap SignalFormatMap; 
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FormatMap ResultFormatMap; 
Stream FunctionaJTestStream; 
Stream ConsoleStream; 

} 

5 defines a format group FunctionalTestGroup, which includes a format map 

SignalFonnatMap and a ResultFormatMap. The messages generated from the format group 
are exported to dataiog stream FunctionalTestStream and ConsoleStream. 
[0056] A dataiog format map block may be used to remove an existing dataiog format 
group from the dataiog system. In this case, the dataiog API 

10 

void DatalogManager::removeFormatGroup(const OFCString 
&groupName); 

is called to perform the function. 

15 Dataiog System Application Examples 

[0057] In the following exaihples, proxy objects, such as DatalogManagerProxy, 
DatalogHandelerProxy, and DatalogFilterProxy, are used by applications running the 
system controller to remotely control the current state and operation of the dataiog 
framework on one or more site controllers. These objects act as remote proxies for the real 

20 objects on the site controllers and provide a transparent communication channel to these 
objects that allows applications on the system controller to deal with local object rather 
than the complexities of communication protocols. 

[0058] Figure 6 illustrates an implementation of enabling datalogging dynamically 
according to an embodiment of the present invention. The group of collaborating objects 
25 for achieving this task includes a Dataiog graphical user interface (DatalogGUI) object 602, 
a DataloggerProxy object 604 (also referred to as DatalogManagerProxy), a test object 606 
and a Datalogger object 608 (also referred to as DatalogManager). The sequence diagram 
illustrates the steps for enabling a dataiog system dynamically. As shown in Figure 6, 
each step of the sequence diagram is described as follows: 
30 1 . In step 1 , the DatalogGUI 602 or other tester GUI (e.g.. Test Control Panel) 

includes a button or menu item Enable Dataiog. When a user clicks on the button or 
menu item, the DatalogGUI 602 searches the DataloggerProxy object 604 from a test 
plan server proxy (TPSProxy). 
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2. The DatalogGUI 602 invokes a setEnabIe() method on the returned 
DataloggerProxy 604, passing in parameter value 'true', which means enabling the 
datalog system. 

3. With the proxy model, the setEnableQ method of the DataloggerProxy 604 

5 invokes the setEnableTestQ method of the Datalogger 608 to enable the datalog system. 

4. The test object 606 calls an enteringTestQ method to send out a datalog event to 
the Datalogger 608. 

5. The Datalogger 608 checks whether it is enabled by calling an isEnabledQ 
method. 

10 6. If the Datalogger 608 is enabled, it invokes a log() method to start datalogging. 

[0059] Figure 7 illustrates an implementation of disabling datalogging djmamically 
according to an embodiment of the present invention. The group of collaborating objects 
for achieving this task includes a DatalogGUI object 702, a DataloggerProxy object 704, a 
test object 704 and a Datalogger object 708. The Datalogger 708 may be used to disable 

15 all datalogging. The sequence diagram illustrates the steps for disabling a datalog system 
dynamically. As shown in Figure 7, each step of the sequence diagram is described as 
follows: 

1 . In step 1, the DatalogGUI 702 or other tester GUI (e.g., Test Control Panel) 
includes a button or menu item Disable Datalog. When a user clicks on the button or 

20 menu item, DatalogGUI searches the singleton DataloggerProxy object 704 from a 
TPSProxy. 

2. The DatalogGUI 702 invokes a setEnableQ method on the returned 
DataloggerProxy 704, passing in parameter value 'false', which means disabling the 
datalog system. 

25 3. With the proxy model, the setEnableQ method of the DataloggerProxy 704 

invokes the setEnableTestQ method of the Datalogger 708 to disable the datalog 
system. 

4. The test object 706 calls an enteringTestQ method to send out a datalog event to 
the Datalogger 708. 

30 5. The Datalogger checks whether it is enabled. Since it is disabled, no datalogging 

may occur. 

[0060] Figure 8 illustrates an implementation of modifying datalog format dynamically 
according to an embodiment of the present invention. The group of collaborating objects 
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for achieving this task includes a DatalogGUI object 802, a DatalogFormatterProxy object 
804, a DatalogHandler object 806, and a DatalogFonnatter object 808. The sequence 
diagram illustrates the steps for changing the datalog format dynamically. The 
DatalogHandler object 806 allows users to combine datalog stream and format 
5 specifications together in a single entitle that the DatalogManager may use to pass datalog 
events to. As shown in Figure 8, each step of the sequence diagram is described as 
follows: 

1 . In step 1 , the DatalogGUI 802 displays a list of available datalog formatters 
associated with a selected datalog handler. A user may select any datalog formatter by 

1 0 opening a pull-down menu, and selects the menu item Edit. The implementation of 
DatalogGUI associates each datalog formatter item in the list with the corresponding 
datalog formatter proxy reference (by using user data parameter). Next, the 
DatalogFormatterProxy object 804 is obtained. 

2. The DatalogGUI 802 invokes a getFormat() method using the 

15 DatalogFormatterProxy object 804 to get the format string and related arguments. 

3. With the proxy model, the getFormat() method of the DatalogFomiatterProxy 804 
invokes the corresponding getFormatQ method of the DatalogFormatter 808. 

4. The DatalogGUI 802 displays the format and argument of the datalog event with 
the selected formatter. The user may change the format and argument according to a set 

20 of predetermined datalog format requirements . 

5. When the user applies the modified formatter into the datalog system, the 
DatalogGUI 802 invokes a set^'ormat() method of the DatalogFormatterProxy 804 and 
passes in the modified format string and arguments. 

6. With the proxy model, DatalogFormatterProxy.setFormatQ method of the 
25 DatalogFormatterProxy 804 invokes the corresponding setFormatQ method of the 

DatalogFormatter 808. 

7. Next, when the DatalogHandler 806 invokes a getOuptutQ method on the 
modified datalog formatter to get formatted message with the datalog event, the 
modified formatter is applied. 

30 [0061] Figure 9 illustrates an implementation of assigning datalog output streams 
dynamically according to an embodiment of the present invention. The group of 
collaborating objects for achieving this task inclvides a DatalogGUI object 902, a 
DatalogManagerProxy object 904, a IDatalogHandlerProxy object 906, a IDatalogHandler 
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object 908, and a DatalogManager object 910. The sequence diagram illustrates the steps 
for assigning datalog output streams to associate with a datalog handler dynamically. As 
sliown in Figure 9, each step of the sequence diagram is described as follows: 

1 . In step 1, when a user selects a datalog handler to edit its associated datalog 

5 output stream, the DatalogGUI 902 displays a panel, which comprises two lists: a first 

list displays datalog stream names in the datalog system, and a second hst displays the 
datalog stream names associated with the datalog handler. In addition, the DatalogGUI 
also includes Add, Remove, Apply, OK and Cancel buttons. 

2. The DatalogGUI 902 calls a getStreamNamesQ method of the 
10 DatalogManagerProxy 904. 

3. With the proxy model, the getStreamNamesQ method of the 
DatalogManagerProxy 904 invokes the corresponding getStreamNamesQ method of 
the DatalogManager 910 to get all datalog stream names registered in the datalog 
system. 

15 4. The DatalogGUI 902 displays the retrieved datalog stream names in the first list. 

5. The DatalogGUI 902 then calls a getStreamNamesQ method of the 
IDatalogHandlerProxy 906. 

6. With the proxy model, the corresponding getStreamNamesQ method of the 
IDatalogHandlerProxy 906 invokes the corresponding getStreamNamesQ method of 

20 the IDatalogHandler 908 to get all datalog stream names currently associated with the 
selected datalog handler, 

7. The DatalogGUI 902 displays the retrieved datalog stream names associated with 
the selected datalog handler in the second list. 

8. Then, the user edits the associated datalog stream list using the buttons Add and 
25 Remove, After the user finishes editing and clicks an Apply or Ok button to apply the 

modified stream to the datalog system, the DatalogGUI 902 invokes a setStreamsQ 
method on the IDatalogHandlerProxy 906 and passes to it the modified datalog stream 
names. 

9. With the proxy model, the setStreamsQ method of the IDatalogHandlerProxy 906 
30 invokes the corresponding setStreamsQ method of the IDatalogHandler 908. 

10. Then, the IDatalogHandler 908 gets the associated datalog stream object reference 
for each datalog stream name firom the DatalogManager 910. 
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1 1 . The IDatalogHandler 908 then adds the stream into the stream vector. Afterwards, 
the IDatalogHandler 908 sends out newly selected datalog streams in the stream vector 
for its datalog output. 
[0062] Figure 10 illustrates an implementation of disabling datalog output stream 
5 dynamically according to an embodiment of the present invention. The group of 
collaborating objects for achieving this task includes a DatalogGUI object 1002, a 
IDatalogStreamProxy object 1004, a IDatalogHandler object 1006 and a IDatalogStream 
object 1008. The sequence diagram illustrates the steps for disabling a datalog output 
stream dynamically. As shown in Figure 10, each step of the sequence diagram is 
10 described as follows: 

1 . In step 1 , the DatalogGUI 1 002 displays a list of available datalog streams. A user 
may select any datalog stream by opening a pull-down menu, and selects a menu item 
Disable. The implementation of the DatalogGUI 1002 associates each datalog stream 
item in the list with the corresponding IDatalogStreamProxy reference 1004 (by using 

15 user data parameter). Then, the IDatalogStreamProxy 1004 is obtained. 

2. The DatalogGUI 1002 invokes a disableQ method on the IDatalogStreamProxy 
object 1004 obtained. 

3. The disableO method of the IDatalogStreamProxy 1004 invokes the 
corresponding disableQ method of the IDatalogStream 1008 through the proxy model. 

20 4. The IDatalogHandler 1 006 calls a writeQ method to write out a formatted 
message to the stream. 

5 . The IDatalogStream 1 008 checks whether it is enabled. If it is enabled, the output 
stream may be modified. 
[0063] Figure 1 1 illustrates an implementation of adapting new source dynamically 

25 according to an embodiment of the present invention. The group of collaborating objects 
for achieving this task includes a DatalogGUI object 1 102, a DatalogManagerProxy object 
1 104, a test object 1 106, a Datalogger object 1 108, a DatalogManager object 1 1 10, a 
DatalogHandlerProxy object 1 1 12, a DatalogHandler object 1 1 14, a DatalogFilterProxy 
object 1 1 16, a DatalogFilter object 1118, and a DatalogFormatter object 1 120. The 

30 sequence diagram illustrates the steps for adapting new source dynamically. The 

DatalogFilter object 1118 allows users to selectively filter datalog events by type and 
source identifiers. This filtering allows users to turn on and off specific datalog events. As 
shown in Figure 11, each step of the sequence diagram is described as follows: 
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1 . In step 1 , the DatalogGUI 1 102 finds the DatalogManagerProxy object 1 104, and 
calls its addHandlerO method to register a new DatalogHandler instance for the new 
source. Note that in this approach, the DatalogHandler 1114 associates an event with a 
different Datalog Formatter. With this model, a new DatalogHandler instance is 
created to work with the new source (test class). The newly created 
DatalogHandlerProxy instance is returned. 

2. With the proxy model, the addHandlerQ method of the DatalogManagerProxy 
1 104 invokes the corresponding addHandlerQ method of the DatalogManager 1110. 

3 . Next, the addHandlerQ method of the DatalogManager 1110 creates a new 
instance of DatalogHandler, then it registers the newly created DatalogHandler 
instance to the DatalogManager 1110. 

4. Then, the DatalogGUI 1 102 associates the datalog filter proxy with the newly 
created datalog handler through the DatalogHandlerProxy 1 104 returned in step 1. 

5 . With the proxy model, the getFilterQ method of the DatalogHandlerProxy 1112 
invokes the con-esponding getFilterQ method of the DatalogHandler 1 1 14. 

6. With the DatalogFilterProxy 1 1 1 6, the DatalogGUI 1 1 02 calls its enableTestQ 
method. 

7. With the proxy model, the enableTestQ method of the DatalogFilterProxy 1116 
invokes the corresponding enableTestQ method of the DatalogFilter 1 1 18. As a result, 
the newly created datalog handler instance handles a selected event of the new test 
source. 

8. The DatalogGUI 1 1 02 sets the formats for each selected datalog event of the 
newly created datalog handler through its proxy. For this new test source, the format of 
a new argument may be specified as TestFooArgument. In the new test source, an 
interface IProperty may be implemented, which is shown as follows: 

class IProperty 
{ 

public: 

OFCString &getProperty(const OFCString &name) const; 
void,setProperty(const OFCString &name, const OFCString 

*value); 

OFCStringVecJ getPropertyNamesQ const; 

}; 

where FooArgument is one of the properties in the new test source. 
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9. The DatalogHandlerProxy 1112 calls a setFormatQ method thought the 

corresponding DatalogHandler 1114. 

10. The DatalogHandler 1114 creates a DatalogFormatter for the selected event and 
adds it into the event route map. Next, the newly created datalog handler processes the 

5 datalog event from the new source. Then, the test plan with the new source test may 

start. 

1 1 . Once the TPS reaches the end of execution of the new source test, it sends an 
exitingTestO datalog request to the datalog system. 

12. The Datalogger 1 1 08 accepts the request, and transfers it to the datalog event to 
10 be logged. 

1 3 . The Datalogger 1108 forwards the new datalog event to the DatalogManager 1110 
to dispatch. 

14. The DatalogManager 1110 publishes the event to the registered datalog handlers 
one by one. Once a datalog handler is able to process the event, the publishing process 

1 5 may be stopped. 

1 5 . When the event is pubUshed to each datalog handler, the handler checks whether 
the event is loggable. The event is loggable if the newly created DatalogHandler 
instance is able to service the new test source. 

16. The DatalogHandler 1 1 14 finds the DatalogFormatter 1 120 associated with the 
20 current event, and calls its getOuptutQ method to get the formatted message based on 

the defined format. The getOuptutQ method fetches the new parameter 
Test.FooArgument value by calling 

event.getDatalogger->getTest()->getProperty("FooArgument"); 

25 

the formatted output message is then forwarded to the output datalog stream. 
[0064] There are number of benefits achieved by the disclosed datalog framework. 
First, the datalog framework is independent of the sources, nature and contents of the 
datalog events. This allows new datalog sources and events to be added without modifying 
30 the datalog framework. In addition, the formatting of datalog output is independent of the 
datalog framework. While the GeneralFormat is provided with the system, it is specified 
as a dynamically linked library (DLL) parameter to the Format block, and it is not "hard- 
coded" into the framework. Moreover, the formatting of datalog events is configurable by 
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the end user. For example, events may be formatted into human readable text, comma- 
separated values for spreadsheets or databases, application-specific text or binary formats 
for further processing, or they may even be ignored entirely. The datalog framework is 
independent of the destination of datalog streams. Furthermore, formats and output 
5 streams are extendable. That is, users may add new IDatalogFormat and IDatalogStream 
implementations to the system without modifying the framework. Test classes (and other 
datalog sources) and their corresponding datalog events are also extendable so the 
framework does not need to know .about specific source or event types. As users add new 
Test classes with new datalog event types, no modification of the datalog framework is 
10 required. 

[0065] One skilled in the relevant art will recognize that many possible modifications 
of the disclosed embodiments may be used, while still employing the same basic 
underlying mechanisms and methodologies. The foregoing description, for purpose of 
explanation, has been written with references to specific embodiments. However, the 

1 5 illustrative discussions above are not intended to be exhaustive or to limit the invention to 
the precise forms disclosed. Many modifications and variations are possible in view of the 
above teachings. The embodiments were chosen and described to explain the principles of 
the invention and its practical applications, and to enable others skilled in the art to best 
utilize the invention and various embodiments with various modifications as are suited to 

20 the particular use contemplated. 
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CLAIMS 

What is claimed is: 

5 1. A method for communicating test information from a source to a destination, 
comprising: 

providing a modular test system, wherein the modular test system comprises a 
system controller for controlling at least one site controller, the at least one site controller 
for controlling at least one test module; 
10 providing a datalog framework for supporting extension of user-defined datalog 

formats; 

providing support classes for supporting user-initiated datalog events; 
receiving a datalog event requesting for communicating input test information from 
the source to tlie destination; 
1 5 configuring output test information based upon the destination, the datalog 

framework and the support classes; and 

transferring the output test information to the destination. 

2. The method of claim 1 , wherein the datalog framework comprises: 

20 a source interface for supporting the input test mformation of individual sources 

firom different vendors; 

a type interface for representing classes of datalog sources and destinations; 
a format interface for providing formatting capabilities; 
a stream interface for transferring formatted test information to different 
25 destinations; and 

a datalog manager for managing datalog ievents in response to the corresponding 
sources, streams, formats and destinations. 

3 . The method of claim 1 , wherein the support classes comprise : 

30 a datalog value class for storing header, type and event information; 

a datalog format map class for combining a type and a name of a user event; 
a datalog format group class for bundling a group of format maps; 
a user format class for supporting user-defined format classes; and 
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a general format class for supporting a set of predefined format classes. 



4. The method of claim 1 , wherein the step of providing the datalog framework 
further comprises: 

5 creating one or more datalog streams; 

creating one or more user formats; 
creating one or more datalog format maps; 
creating one or more datalog format groups; and 

linking the one or more datalog streams, user formats, datalog format maps and 
1 0 datalog format groups to a corresponding datalog manager. 

5. The method of claim 1 , wherein the datalog framework is independent of the 
source and contents of input test information. 

15 6. The method of claim 1 , wherein the datalog framework is independent of the 
destination and contents of output test information. 

7 . The method of claim 1 , wherein formats of the output test information are 
configurable by users. 

20 

8. The method of claim 1 , wherein the step of configuring comprises: 

creating a datalog value object, the datalog value object including type and event 
information; 

determining a datalog format object based upon the corresponding destination, 
25 datalog framework and support classes; and 

formatting the output test information using the datalog format object. 

9. A modular test system, comprising: 
a system controller; 

30 at least one site controller coupled to the system controller; 

at least one test module and its corresponding device under test (DUT); 
a datalog framework configured to support extension of user-defined datalog 
formats; 
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one or more support classes configured to support user-initiated datalog events; 
means for receiving a datalog event requesting for communicating input test 
information from the source to the destination; 

means for configuring output test information based upon the destination, the 
5 datalog framework and the support classes; and 

means for transferring the output test information to the destination. 

1 0. The system of claim 9, wherein the datalog framework comprises : 

a source interface for supporting the input test information of individual soiirces 
1 0 from different vendors; 

a type interface for representing classes of datalog sources and destinations; 
a format interface for providing formatting capabilities; 
a stream interface for transferring formatted test information to different 
destinations; and 

1 5 a datalog manager for managing datalog events in response to the corresponding 

sources, streams, formats and destinations. 

1 1 . The system of claim 9, wherein the support classes comprise: 

a datalog values class for storing header, type and event information; 
20 a datalog format map class for combining a type and a name of a tiser event; 

a datalog format group class for bundling a group of format maps; 
a user format class for supporting user-defined format classes; and 
a general format class for supporting a set of predefined format classes. 

25 12. The system of claim 9, wherein providing the datalog framework further 

comprises; 

means for creating one or more datalog streams; 
means for creating one or more user formats; 
means for creating one or more datalog format maps; 
30 means for creating one or more datalog format groups; and 

means for linking the one or more datalog streams, user formats, datalog format 
maps and datalog format groups to a corresponding datalog manager. 
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13. The system of claim 9, wherein the datalog fi-amework is independent of the 
source and contents of input test information. 

14. The system of claim 9, wherein the datalog framework is independent of the 
5 destination and contents of output test information. 

1 5 . The system of claim 9, wherein formats of the output test information are 
configurable by users. 

10 16. The system of claim 9, wherein the means for configuring output test information 
comprise: 

means for creating a datalog value object, the datalog value object including type 
and event information; 

means for determining a datalog format object based upon tlie corresponding 
15 destination, datalog framework and support classes; and 

means for formatting the output test information using the datalog format object. 
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